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HISTORICAL PERSPECTIVE 



FORTH was oreatad by Hr. Charlas H. 
Moore In about 1969 at the National Radio 
Aatronony Obaepvatory, Charlottasvilla , VA. 
It was created out of his dlasatlafaotlon 
with available prograaolng tools, eapaolalljr 
Tor autoaatlon. Dlatrlbutlon of hla work to 
other observatories has aade PORTH tha 
de-facto standard language Tor obaarvatory 
automation. 



Hr. Hoore and several aaaoclates 
formed Forth Inc. In 1973 for tha purpose 
of licensing and support of the FOBTH 
Operating Systea and ?rogramnlng Language, 
and to supply application prograoalng to 
■eat customers ' unique requirements. 



FORTH enjoys a synarglan of its 
features. It has none of the elephantine 
characteristics of PL/1 or FORTRAH. It has 
a density and speed far surpassing BASIC, 
but retains an interactive nature during 
program devalopoent. Slnoa it la 

extensible, special words are easily defined 



to glva It tba taraanaas of APL. It* 
clarity and conslstenoy raaalt froa balng 
tha product of a single alnd. (aa wara API 

and PASCAL). 



Although the languaga •paelfloatlen and 
■any lapleaantatlona are In tha public 
domain, aany other lapleaentatlona and 
application packages are aTallable aa 
prograa products of eoaaarolal auppllera. 



The FORTH Interaat Group la oentered In 
Northern California. It waa foraad in 1978 
by local FORTH prograaaera to eaeourmc* 
of the language by the Interchange -of tdeaa 
though aealaara and publte«tl»na. About 300 
■aabera are presently associated into a 
loose national organization. ('Loose' aeans 
that no budget eKlsts to aupport any foraal 
affort.) All effort Is on a volunteer baaia 
and tha group la asaoolatod with no vendors. 

;S W.F.R 8/20/78 



CONTRIBUTED MATERIAL 



FORTH Interest Groups neeck the fol lowing matertal ; 

1. Technical nrteriol far Inclusion in FORTH DIMENSIONS, Both 
expositions on Intemoi features of FORTH and application prograim ore appreciated. 

2. Nome and address of FORTH Implementations for inclusion in our 
publicod'ions. Include computer requirements, documentation and cost. 

3. Manuals ayaild>le for distribution. We con purchase copies and distribute, 
or print irom /our authorized original . 

4. Letters of genera I trtferest for publication in this newsletter. 

5. Users who may be r e f eren c ed for local denonatration to newcomers. 
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DTC VERSUS ITC FOR FORTH ON THE PDP-11 



By David J. Sirag 
Laboratory Software Systeas^ Inc. 
3634 HandeviUe Canyon Road^ Los Angeles^ CA 90049 



During the design of LABFORTH, the FORTH implementation by 
Laboratory Software Systems, the choice had to be made between direct 
threaded code (DTC) and indirect threaded code (ITC). A detailed 
analysis showed DTC to be significantly superior to ITC in both speed 
and size. This analysis contradicts the findings of Dewar (ACM June 
1975) which were referenced in the "Threaded Code" article in the 
August 1978 issue of FORTH Dimensions. Dewar compared his use of ITC 
with DTC as used for PDP-11 FORTRAN. His analysis does not apply to 
the implementation of FORTH on the PDP-11. 



The FORTH analysis involves 3 types of definitions - low level 
(CODE), high level (COLON), and storage ( var i ab le ,e t c ) . The low level 
definitions will be encountered most frequently by far because of the 
pyramidal nature of FORTH definitions. On the other hand, storage 
definitions will be encountered far less frequently in FORTH than in 
FORTRAN because in FORTH the stack is used extensively while in 
FORTRAN no stack is available. Also, when storage locations are used 
in FORTH operators are available which minimize the number of 
references. For example, in FORTRAN 

COUNT = COUNT ♦ 1 

involves 2 references to the variable COUNT, while in FORTH 

COUNT 1+! 

involves only 1 reference. It should be noted that in LABFORTH, 1+! 
is a primitive, but it is not in some other versions of FORTH. 
Another factor which reduces the references to storage locations is 
that in FORTH literals are placed in line and handled by a reference 
to the LITERAL (low level) routine. 

The OTC and ITC routines for the 3 types of definitions are shown 
below, they are condensed to show only the relative PDP-11/40 
overhead. The register notation in the routines is as follows: 

Q is the cue register (R5) which points to the next address. 
It is called IC (instruction counter) in some literature. 

S Is the stack pointer (R4). 

R is the return stack pointer (R6). 

P is the program counter (R7). 

RO is a temporary register assumed to be available. 

— > 
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OTC AND ITC ROUTINES 



LOW 
LEVEL 

DEFINITION 
(CODE) 



NAME 
S 

LINK 



MACHINE 
CODE 



OVERHEAD 
1 WORD 
2.3 USEC 

= NEXT 



NAME 
S 

LINK 



CODE ADDR 



MACHINE 
CODE 



MOV (Q)+,RO 
JWP a(RO)* 



OVERHEAD 
3 WORDS 
A. 6 USEC 



= NEXT 



HI6N 
LEVEL 

DEFINITION 
(COLON) 



STORAGE 
DEf INITIOK 
<VARAI«L€) 



NAME 
K 

UNJL 



JSR Q^a(P)< = NEST 



AODRESSES 



ADR UNNEST 



OVERHEAD 
2 WORDS 
8.0 USEC 



NAME 

S 

1.INK 



CODE ADDR 



ADDRESSES 



ADR UNNEST "h y 



NEST: 
^MOV Q,-(R) 
MOV RO^Q 
MOV • 2)+,R0 
J«P a(«0)* 

OVE«HEAD 
2 WORDS 
U.O US£C 



UNNEST; 



MOV {R)+,CI 
JMP a(Q>+ 



UNNEST: 



MOV (R)+^Q 
MOV (Q)-*^,RO 
JMP a(RO)* 




■ CALL VAK 

OVERHEAD 
2 WORDS 
5.7 USEC 



VAR: MOV (R)+^-(S) * 
JMP a<Q)* 




OVERHEAD 
1 WORD 
4.6 USEC 

VAR: MOV RO,-(S) * 
MOV (Q)*,RO 
JMP a(RO)* 



♦ Tt»e push instruction Itself is not counted in the overhead 
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The distinction between OTC and ITC as applied to FORTH is that 
in OTC executable machine code is expected as the first word after the 
definition name; while, in ITC the address of the machine code is 
expected. Thus the DTC space advantage in the entry to a low level 
definition is obvious. The machine code of the low level definition 
terminates with the "NEXT" routine. In DTC NEXT is a 1 word routine 
while in ITC the extra level of indirection results in a 2 word 
routine (Note: a JMP NEXT would also take 2 words). 



In the high level definition the machine code of the "NEST" 
routine is stored in line for OTC, but since it is only 1 word, it 
takes no more room than the pointer to the "NEST" routine. However, 
the 1 instruction for OTC takes considerably less time to execute than 
the A instructions for ITC (Note: replacing the last 2 instructions 
with JMP NEXT would take even more time). The remaining words in the 
high level definition are addresses in both cases. The last address 
points to the UNNEST routine which again is more complex for ITC 
because of the additional indirection. 



In the storage definition case the machine code of the subroutine 
call to the appropriate processor (VAR in the example) is stored in 
line. This requires 2 words not including the the storage for the 
variable itself. The storage words follow the call and can be thought 
to be the parameters for the call. Thus in this case, the 1 word code 
address for ITC represents a 1 word advantage over the subroutine 
call. The execution time is also slightly in favor of ITC, even 
though 3 instructions are executed in both cases. 





DTC VERSUS 


ITC OVERHEAD SUMMARY 






Il£ 


OTC ADVANTAGE 


Low level 
(CODE) 


1 word 
2.3 usee 


3 words 
A. 6 usee 


2 words 
2.3 usee 


High level 
(COLON) 


2 words 
8.0 usee 


2 words 
1A.0 usee 


words 
6.0 usee 


Storage 
(VARIABLE) 


2 words 
5.7 usee 


1 word 
A. 6 usee 


-1 word 
-1.1 usee 



The summar/ table shows that DTC has the overhead advantage in 
both low level and high level definitions; while ITC has the advantage 
in storage definitions. Considering the high occurrence of low level 
definitions and the low usage of storage definitions, one can see that 
a FORTH implenentation with DTC has a significant speed and space 

— > 
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advantage over one using ITC. To make the advantage more concrete 
weights should be assigned to the various definition types. If we 
have a program containing 500 definitions (including the standard 
FORTH definitions), we might expect 200 low level.. 250 high level, and 
50 storage definitions. Using these numbers the size advantage of low 
level, high level, and storage should be weighted .4, .5, and .1 
respectively. During the execution of a program, we might expect the 
frequency of occurrence of low level, high level, and storage to be 
60X, 20X, and 20% respectively. The result of applying these weights 
is shown in the following table. 





WEIGHTED ADVANTAGE OF DTC 


OVER ITC 




SIZE ADVANTAGE 


SPEED ADVANTAGE 


Low level 


2 X .A = .8 words 


2.3 X .6 = 1.38 usee 


High level 


X .5 = words 


6.0 X .2 s 1.2 usee 


Storage 


-1 X .1 = -.1 words 


-1.1 X .2 * -.22 usee 


Weighted advantage .7 words 


2. A usee 



Thus using the weighted advantage for DTC we would expect to save .7 
words in each of the 500 definitions which is a total of 350 words. 
Also each time a definition is executed the overhead would be 2. A usee 
l«ss. This may represent a savings of 20 or 30X of the total 
execution time of the frequently used short definitions. 



The remaining advantage that is claimed for ITC is one of machine 
independance because no machine code appears in the code generated by 
the compiler. But even this advantage is illusionary since FORTH 
programs are transported in source form. In fact on most systems they 
are compiled each time they are loaded via the LOAD command. Thus^ 
after a FORTH system is hosted on a given computer, the machine code 
that is generated by the compiler is suitable for that particular 
machine; this includes the machine code generated for the DTC 
routines. If one did try to introduce the concept of FORTH 
portability at the object code level by restricting the programs to 
high level definitions and placing all machine code in a run-time 
package, he would still probably have machine dependencies in byte 
versus word addresses, floating point format, and character string 
representation. In any case, current FORTH implementations do not 
claim transportability at the object code level. 
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FORTH Interest Group 
787 Old Country Road 
San Carlos, CA 94070 



LABORATORY SOFTWARE SYSTEMS. INC. 



3634 MANDEVILLE CANYON ROAD 
LOS ANGELES. CALIF. 90049 
(213)472-6995 



Dear Figgy, 

FORTH Dimensions is just the sort of communications vehicle which 
is needed by the FORTH community for both users and vendors. My 
payment for a subscription is enclosed. 

As Dr. R.M. Harper indicated in an earlier letter, we at 
Laboratory Software Systems have developed a version of FORTH on the 
POP-11 called LABFORTH. As the name implies, LABFORTH contains 
features which make it particularly suitable for the scientific 
laboratory environment. This environment includes high speed data 
collection and analysis; thus particular attention is given to making 
LABFORTH fast. For this reason the direct versus indirect threaded 
code discussion in the Thread Code article in the August / Sept embe r 
1978 issue of FORTH Dimensions was of particular interest. Our 
analysis of DTC versus ITC was an important aspect of the effort to 
design LABFORTH for maximum speed. DTC proved to be faster than ITC 
and as a bonus required less space. An article on this analysis is 
enclosed for your paper. It contradicts Oewar's analysis of DTC 
versus ITC for DEC's FORTRAN, but his analysis cannot really be 
applied to FORTH. If DEC had used DTC in a more elegant manner, DTC 
may also have fared better in the FORTRAN case. 



Hopefully the DTC advantages will persuade you to delete the 

requirement that FORTH be implemented with ITC. The programming 

techniques used in implementing FORTH ought to be left to the designer 
and his results should to be evaluated by benchmarks. 



I look forward to your next issue of FORTH Dimensions. 



FORTH INTEREST GROUP RO. Box 1105 San Carlos, Ca. 94070 




Laboratory Software Systems, Inc. 
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D-CHARTS 
Rla H«rrlB 



An alternative style of flowcharts called 
D-charts will be described. But first the 
purpose of flowcharting will be discussed as 
well as the shortcomings of traditional 
flowchart ing . 

A flowchart should be a tool for the design 
and analysis of sequential procedures which 
make the control flow of a procedure clear. 
With FORTH and other modern languages, 
flowcharts should be optimized for the 
top-down design of structured programs and 
should help the understanding and debugging 
of existing ones. An analogy may be made 
with a road map. This graphic representa- 
tion of data makes it easy to choose an 
optimum route to some destination, but when 
driving, a sequential list of instructions 
is easier to use (e.g. , turn right on 3rd 
street, left on Ave. F, go 3 blocks, etc.). 
Indentation of source statements to show 
control structures is helpful and is recom- 
mended, but a two dimensional graphic 
display of those control structures can be 
superior. A good flowchart notation should 
be easy to learn, convenient to use (e.g., 
good legibility with free-hand drawn 
charts), compact (minimizing off-page 
lines), adaptable to specialized notations, 
language, and personal style, and modifiable 
with minimum redrawing of unchanged sec- 
tions. 

Traditional flowcharting using ANSI standard 
symbols has been so unsuccessful at meeting 
these goals that "flowchart* has become a 
dirty word. This style is not structured, 
is at a lower level than any higher level 
language (e.g., no loop symbol), requires 
the use- of symbol templates for legibility, 
and forces program statements to be crammed 
inside these symbols like captions in a 
cartoon. 



The only 'lines' in Orcharts are used to 
show nonsequential control paths (e.g., 
conditional branches, loops). In a proper 
D-chart, no lines go up; all lines either go 
down or sideways. Any need for lines 
directed up can be (and should be) met with 
the loop symbols. This simplifies the 
reading of a 0-chart since it always starts 
at the top of a page and ends at the bottom. 

It is customary to underline the entry name 
(or FORTH definition nMe) at the top of a 
D-chart. 



2-WAY BRANCH SYMBOL 

In PGRTR, this structure takes the form: 

condition IP true phrase 

ELSB false phrase 
THEN 

Another FORTH structure which is used for 
conditional compilation has more mnemonic 
names: 

condition IPTRUE true phrase 

OTHBFMISE false phrase 
BNDIP 

The D-chart symbol has parts for each of 
these elements: 




false phrase true phrase 



D-charts have a simplicity and power similar 
to FORTH. They are the invention of Prof. 
Edsqer W. Dijkstra, a chiunpion of top-down 
design, structured programming, and clear, 
concise notation. They form a context-free 
language. D-charts are denser than ANSI 
flowcharts usually allowing twice as much 
program to be displayed per page. There are 
only two symbols in the basic language; 
however, like FORTH, extensions may be added 
for convenience. 

Sequential statements are written in free 
form, one below the other, and without 
boxes . 

statement 
next statement 
next statement 



%K>rds following ENDIP (or THEN) 

The "condition" i« evaluated. If It la true, Che 
"true phreee" ii executed: othetwiee, the "falae 
phreae" la executed. The worda following BMDIF 
(or THEH) are unconditionally executed. 

If either phrase is omitted, as with 

condition IP true phrase THEN 
a vertical line is drawn as shown: 
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LOOf SYMBOL 

The basic loop defining syabol for 
D-ch«rt« is properly structured. 



cond i t ion 



loop body 



i 



The switch symbol: 



indicates that when the switch is 
encountered, the ."condition* (on the 
side line) is evaluated. 

1. If the "condition" is true, then 
the side line path is taken; if 
false, then the down line is taken 
(and the loop is terminated). 



A aore general case is 

BBGIN first phrase 
condition if second phrase 
AGAIN 

which is explained better graphically 
than verbally: 



I 

first phrase 

condition 



second phrase 

i 



Both previous symbols may be properly 
nested indefinitely. The following example 
shows how these symbols may be combined. 
This is the FORTH interpreter from the 
F.I.G. model. 



2. If the side line is taken, all 
statements down to the dot are 
executed. The dot is the loop end 
symbol and indicates that control 
is returned to the switch. i 



3. The "condition" is again evalua- 
ted. Its outcome might have 
changed during the execution of 
the loop statement. 

Repeat these steps starting with 
Step 1. 

This symbol tests the loop condition 
before executing the loop body. However, 
other loops test the condition at the 
end of the loop body (e.g., DO .. LOOP 
and BEGIN .. END) or in the middle of the 
loop body. This loop symbol may be 
extended for these other cases by adding 
a test within the loop body. Consider 
the FORTH loop structure 

BEGIN loop body condition END 

The loop body is always executed once, 
and is repeated as long as condition is 
false. The D-chart symbol for this 
structure would be: 



: INTERPRET BBGIN ('} IP HERE NUMBER 

ELSE EXECUTE 
THEN 

7 STACK 
AGAIN ; 

INTERPRET 

1 until null word executed 



search dictionary for next word 




check stack 



i 
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n-WAY BRANCH SYMBOL 

A structured n-way branch symbol (some- 
times called a CASE statement) may be 
defined for convenience. (It is func- 
tionally equivalent to n nested 2-way 

branches). One style for this symbol 



first case 



second case 



last case 



The condition is usually an index which 
selects one of the cases. The rejoining 
of control to a single line after the 
cases are required by structured program- 
ming. Depending on the complexity of 
the cases, this symbol may be drawn 
differently. 



D-charts are efficient and useful. They are 
vastly superior to traditional flowchart 
style. 



;S KIM HARRIS 



P.O. Box 8045 
Austin, TX 78712 
November 3, 1978 

Editor, Forth Oiaiensians: 

Thank you for your card and subsequent letter. 
I am sorry that I did not get back to you sooner with 
a copy of the source code for my FORTH system. 
Franltly, I was surprised that you are interested in 
the system, since it is rather limited in facilities 
and oonfonns with no other POBOT version in terns of 
names. I stopped worlc on the system just about the 
time I began to receive namuals fovn DECUS and the 
6502 FORTH form PIG. I can see now how I would add 
an assembler, text editor, and random block i/o to 
the system, but my duties at work and at school 
preclude any further development of O.T. FOfCTH for 
now. 

I want to especially thank you for informing 
me of Paul Baurtholdi's visit to the University of 
T>°xas. I was able to meet with him and we had a very 
stimulating discussion for about an hour and a 
half. I was surprised to learn from him how widely 
FORTH is used commercially, though usually under 
other names. We also discussed two extensions to the 
language that I believe greatly enhance it: (1) 
synteut checking on conpilation for properly balanced 
BEGIN. .END and IF.. ELSE. .THEN constructs, and (2) the 
functions "n PAJWETEiB" and "PARJ" to "PASN" that 
allow explicit reference to parantetera on the stack. 
Finally, he showed me some prograaning examples 
fran the PORlfl manual he wrote whidi provide first- 
hand proof of the ease of programming rather sophis- 
ticated problems in FORTH. It is especially im- 
portant because most people in the conputer science 
department here respond to my presentation of FORTH 
with a resounding lack of interest. After all, they 
keep abreast of the field and if they have not heard 
of it.... 

I have been promoting FORTH among the local 
conixiter clubs and look forward to the results of 
FIG'S micro conputer efforts. Please keep in touch. 

Sincerely yours, 
Greg Walker 
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SYSTEM LANGOAGE 1 



Sl/1 vas written by Qqperic&l Research Group, Inc. 
to be exactly >^at it says it is, a SYSTEM language. 
SI/1 is a saall interactive incremental conpiler that 
generates Indirect threaded code. It is a 16 bit 
peeudo machine for use on mini and micro oonputers. 
New definitions can be added to an already rich set 
of intrinsic instructions. It is this extensibility 
that allows any user to create the most optimum 
vocabulary for his individued application. 

SL/1 is a virtual stack processor. Using the 
HPN concept for both variables and instructions makes 
it possible to extend stepwise programing to include 
stepwise debugging. SI/1 does this tjjite nicely. 
Ttie RPN stack is also one of the most effective means 
of inplementlng top down design, bottom up coding. 

St/1 operates on a principle of threaded code. 
All of the elanents of SI/1 (procedures, variable, 
conpiler directives, etc.) reference the previous 
entry. Thus, each code indirectly "threads" the 
others and is in turn threaded by the code following 
it. Because Sl/1 is a pseudo machine, portability 
between different processors and hardware is readily 
acoont)lished. The low level interpreter is really 
the P-machine. It is small (only 11 bytes are used), 
and fast. 

One of the most powerful features of SI/1 Is the 
fact that is uses all on-line storage media as 
virtual memory. In effect the user can write 
programs in SI/1 using the full capacity of disk 
storage and never be concerned with placement of 
information on the disk. Sl/1 allows you to program 
machine code procedures in assembler using a high 
level language. This can optimize I/O or math 
routines. 

The above information vas excerpted fran a press 
release of November 3, 1978. For further informa- 
tion, contact Mr. Dick Jones, Bnperical Research 
Croup, Inc., 28206 144th Avenue, S.E., Kent, WA 
98031. Phone (206) 631-4851. 
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toroH vs. ASsaeLY 
By Richard B. Main 
Neptune UES, Pleasanton, OV 



Here are sooie facts regarding Forth object 
size and exeuction speeds versus Assembly coding. 

Ftorth, Inc., some progratmers (myself included), 
and others have made some pretty incredible state- 
ments about Forth code resulting in less memory 
required (I) areJ execution speeds as fast as Assentoly 
written code (!!). to help clear the air I'll try to 
explain those two outrageous claims. 

First, Forth code can run as fast, but not 
faster, using a constructional statement called 
•Code" which is followed by a sort of mneumonic 
machine code string and a jump back to the Forth 
inner interpreter. It isn't reasonable to just have 
one big code statement for the whole program. So 
this gets us into another Forth constructional 
statement called a "colon definition". 

Colon statements cost speed but save program 
memory over Assesrbly. Colon statements constitute 
the "high level" aspect of Porth but let's get back 
to the point. 

An exanple "code" statement in Forth to handle 
the character input from a CRT to an Intel SBC 80/20 
would be: 



CODE KEY 



BEGIN ED INP RHC PRC CS END 

EC INP A L NCV H MVI HPUSH JMP 



NOre: Forth code statements allow begin-end 
and if-else-then constructs within the 
assembly. Also Forth requires source- 
destination-operand organization of each 
assenfely statement (A L MCV instead of NOV 
L,A). 

"ttiis exact seae routine in Assembly lanr- 
guage would be: 



KEY: 
BEGIN: 



ElO: 



ORG $ 


; place in next avail 


IN BDH 


; input CRT status 


RRC 


(•rotate receiver ready 


RRC 


; into carry bit 


JtK BEGIN 




IN BCH 


; input CRT data 


MOV L,A 


;push data on 


MVI H,0 


; stack in 16-bit 


JMP HPUSH 


; format 



•nie above examples v*iile not especially excitir^ 
on the surface are quite interesting when you're 
actu^LIly writing these programs on a system installed 
with Forth and one that isn't. Using standard 
disk-based Assembler systan you'd probably have to 
open an edit file, write the program, close tne edit 
file, cadi the ctssembler, and load the object file so 
you could use the debog program to execute. Maybe 
10-30 minutes depending on the problems you have 
along the way. In Forth, you'd enter the code 
statement on the command line, carriage return, 
type "KEY", (CR), and it's executing. 30 seconds 
maxinun! If you liked the way "KEDf" executed you'd 
save it off on the disk using the Forth Editor. 
(Another 20 seconds.) 

the colon statement in Ft)rth was said to save roan 
in memory over Assembly, and provide the hign level 
language ability. An example code statement that 
would read the CRT keyboard conniand messages and then 
execute the desired action could look like: 



KEYBOARD 



64 DO KEY 7F AND DUP = 
IF LEAVE THfH UXP EXECUTE 



Keyboard is the label of this routine. Every 
other word (DO, KEY, AND, =, LEAVE, TOEN, UXX> , and 
EXECUTE) requires two bytes of memory, i^-bit numbers 
require 3 bytes, 1 for the nunber anci 2 for a routine 
that differentiates nimbers from viords and provides 
these numbers on the stack for use by succeeding 
operations, e.g., 64 and for 'DO'. 

The memory saving can be visualized by thinking 
of the routine "keyboard" as a routine that looks 
like: 

KEYBOARD: 



CALL 64 


;a program 


CALL 


;a program 


CALL DO 


;to start a 64 loop 


CALL KEY 


;to inp<it data 


CALL 7F 


;# for AND 


CALL AND 


;to AND it 


CALL DUP 


;to OOP data 


CALL 0D 


;for (CR) test 


CALL IF 


;for (CR) test 


CALL LEAVE 


;if (CR) leave loop 


CALL THEN 


;to conplete IF 


CALL LOOP 


;to loop 64 times 


CALL EXEorre 


; to DO comiand 


CALL ";" 


; to 1X3 next one 



By entering ' KEY fID DUMP on the Forth system 
you'll get the object code displayed as: 

tflflfi DB 0P {IF 02 frjT 4J} DB EC 6F 
26 W C3 41 W 

This is exactly what the Assembly code would 
produce if ORG'ed at AfSfM and the label HPUSH was 
at 41H. 

Reviewing the example Psrth code statanent: "BEGIN" 
p-ax}uced no object but sinply acted aa a label for 
"END" and provided the JNC address for EtD. "OS" 
simply provided the JMP type for EM), in this case 
JNC. "OS NOT a©" would have ooiqplemented the jump 
type and produced JC. 



Looking at it this way, each CALL taxes a byte. 
Fourteen bytes could be saved if the CALL OPCODE 
could be eliminated. The result would be the two 
byte address' of everything to CALL. The innermost 
Forth interpreter uses these address' in sequence arri 
is about 12 bytes of memory code and has the label 
"NEXT". 

Thus, for just this single example, 14 bytes 
were saved, at the cost of 12 bytes for "NEXT". But 
every colon and code statement used "NEXT" so the 
memory savings build because "NEXT" is executed so 
many times. Ttie justification in using sub-routine 
calls in Assembly code versus inline code is based on 
how many times it is called. "NEXT" is completely 
justified because it is called an enormous nunber of 
times. Forth, Inc., has stated "NEXT" would be an 
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excellent micro-oode to be included in a CPO CPCCDE 
set and I'd have to agree. Before a "NEXr" OPCCDE 
would be implemented in MOS processor-1 i)ce 8 085, 
6800, or the like, Ftorth is going to h«»« to become 
quite dear to the industry. So I don't see it 
happening except in some 2900 bit-slice imple- 
mentations. 

All this concern about micro-coding "NEXT" has 
its root. "NEXT" is executed between each wotrj In a 
colon statement and between each vord of a wjrd that 
itself is the name of a colon statement. Therefore, 
"NEXT" slows things down during execution, but ia 
redeeming since it saves space and alloM the high 
level nature of Forth. 

Tto keep things moving quickly in the execution 
of Forth programs, colon statements should contain 
a few words defining the action of the defined colon 

statement and each word should be very closely 
connected to a code statement as possible (since 
code statements run at full machine speed). Also, 
each word in a colon statement should be powerful, 
if the word is the label of a code statement, this 
could mean large code statements. 



I^tge code statements can quickly get oot of hand 
with more than two lines (line in the example of 
"KEY"), because of the lesser ability to ccnnent each 
OPOCSE as in Asseirisly. So Perth, Inc. , has stated 
code statements should be kept short and sweet. It's 
really up to the user to tr^e off readability for 
speed. 

The naming of colon and code statement labels can 
really improve readability If you put aame thought 
into the naming. 

As was said earlier, the fVsrth program statement 
can be executed by entering it on the ccnmand line, 
then typing the nane for execution. Colon statements 
are included in this ability and extremely fast 
coding and debugging is the result. 

I really object to paying $2,500 for any software, 
but Forth is worth it. (They'd probably sell more if 
it wasn't so expensive.) Besides the price ther* 
seems to be a few other inpediments to Fbrth gaining 
a more rapid pDpularity growth. ( 1 ) It does ta)«e 
seme getting used to. (2) There's not many Forth 
systew and programners around. (3) People, in my 
jud^oBnt, are too quick to condenn it. 



|8 RBH 



HIGH SPraO DISK CCPY 
By Richard B. Main 
Neptune UGS, Pleasanton, CA 



TO really get fast disk copies on your W3S-B00 
(TM Intel Corp.) Porth systems, add this program to 
your disking load: 

( HIGH SPEED DISK COPY RBM-7ai001 ) 

1 16384 CONSTANT SCRATCH 

2 2000 CONSTANT BIAS 

3 26 CONSTANT TRACK 

4 4 CONSTANT READ 

5 6 CONSTANT WRITE 

6 26 CONSTANT ALL 

7 : DUPLICATE FMT 77 

8 DO SCRATCH I TRACK * 

9 READ ALL I/O I 

10 SCRATCH I TRACK • 

11 BIAS + WRITE ALL I/O 

12 STATUS IF ( ERROR) LEAVE THEN 

13 LOOP FLUSH CR [ COPY ] 7 ECHO t 

14 ;S DUPLICATE TAKES 80 SECONDS TO 

15 FORMAT AND COPY ENTIRE NEW DISK. 

Ihe main reason this program will take only 80 
seconds to make a copy is whole tracks are read from 
the master disk in drive and whole tracks are 
written to the copy in drive 1. But, alas, you'll 
need 3328 bytes of continuous RAM to run this 
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program. The oonstant named SCRATCH provides the 
first address of the 3328 RAN bytes needed. 

EWLICATE when executed calls FMT to fotaiat the 
disk in drive I. "77 ^ DO" sets up a DO-LOOP to 
copy 411 77 tracks. I/O requires SCRATCH (location) 
I (the track and index of the loop) TRACK • (to 
compute block * for I/O) READ (from drive 0) aixl 
ALL (for # of sectors). I/O will perfoon the disk 
operation. "I" prints the current track being copied 
to entertain the operator. Next, SCRATOi again gives 
the scratch area for I/O and I TRACK • BIAS 
provides the equivalent block number in drive 1 for 
I/O. 

WRITE ALL instructs I/O to write all 26 sectors 
frcm scratch tfea. I/O perform the disk operation. 
{jTKIUS pops the disk status byte from location 20H 
and if non-zero prints ERROR and leaves the loop. 
Else the loop repeats and FLUSH is executed for the 
heck-o£-lt. COPY is printed and BELL is echo'ed to 
CRT to signal conpletlon. 
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